By way of example, user equipment may comprise a fixed or mobile terminal, a residential or business gateway, or indeed a voice gateway such as a SIP-DSLAM (digital subscriber line access multiplexer), i.e. a device that collects digital subscriber line (DSL) data traffic passing over a certain number of telephone lines.
It is said that user equipment “belongs” to the network of a given operator when the user of the equipment possesses an account with that operator, and this applies regardless of the access network used by the user equipment to connect with the operator's network.
Examples of core network servers suitable for performing the present invention are given below.
IP network communications services can identify physical or virtual resources by means of character strings such as a uniform resource identifier (URI). The syntax for URIs is defined in the Internet Engineering Task Force (IETF) document RFC 3986; knowing the URI of a resource makes it possible to obtain the IP address of equipment in the operator's network that manages the resource. In the present description, the term “URI” is used to cover any type of identifier for a physical or virtual application resource that is accessible on the network.
Conventional advanced session protocols, such as the session initiation protocol (SIP) use so-called “signaling” messages, which are messages that enable a terminal to request a connection with another terminal, and also messages that indicate that a telephone line is busy, or that a called telephone is ringing, or that the telephone is connected to the network and can be reached in such-and-such a manner.
The SIP protocol was defined by the IETF in document RFC 3261. That protocol enables multimedia sessions to be set up, modified, and terminated in a network using the IP protocol. The SIP protocol has since been extended, in particular in document RFC 3265. This extension provides for event notification procedures.
In networks that use the SIP protocol, a distinction is drawn between two types of resource identifier: those having the form “SIP-URI”, as defined in RFC 3261, and those having the form “tel-URI”, as defined in RFC 3966. An SIP-URI has the form “sip:user@host” (e.g. sip:alice@domain1), where the “host” portion identifies the domain of the operator responsible for the identity represented by the “user” portion. A tel-URI has the form “tel:telephone_number” (e.g. tel:+33123456789) with reference to international public telephone numbers, or of the form “tel:telephone_number;phone-context= . . . ” (e.g. tel:0623456789;phone-context=+33) with reference to telephone numbers of a format that is valid only in a narrower context (in this example, the ten digit format 0623456789 is valid only within the French numbering plan).
The SIP protocol is used in particular in infrastructures of the IP multimedia subsystem (IMS) type. The IMS was defined by the Third Generation Partnerships Project (3GPP) standards organization and by telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN). It is a network architecture that was introduced by the 3GPP for mobile networks and then taken on by TISPAN for fixed networks. This architecture enables multimedia sessions to be set up dynamically and controlled between two clients and also enables resources to be reserved in the multimedia stream transport network. By means of this architecture, network operators can implement a management policy conveniently, can supply a predetermined quality of service (QoS), and can calculate how much to bill their clients. At present, the IMS makes it possible to access services of the telephone, videos phone, presence, and instant messaging types, and it also manages interactions between them.
When a user seeks to benefit from services made available by an IMS network, the user sends signaling messages to the network that may include in particular various types of request.
Firstly, user equipment needs to register with the network (with some exceptions such as certain emergency calls). When the network is incapable of establishing the link between the registration and an earlier registration (e.g. following a network failure, or after the terminal has been switched off for a period longer than a predetermined value), the registration is considered as being an initial registration. After an initial registration, the equipment must periodically send a request to the network in order to confirm that it seeks to maintain its registration; the registration is maintained only for a predetermined duration, referred to herein as the “registration refresh period” (and often specified in technical literature by the term “expires”); by way of example, above-mentioned document RFC 3261 recommends a registration refresh period of 3600 seconds. In practice, it is the network that informs each user equipment that registers of the value of the registration refresh period with which the equipment is to comply in order to benefit without interruption from the services made available by the network.
Thus, in order to be able to register user equipments, IMS networks have one or more registration servers referred to as serving-call server control function (S-CSCF) servers that are suitable (amongst other things) for managing the procedure of registering devices connected to the network.
In addition, networks have one or more servers known as interrogating-call server control function (I-CSCF) servers—which are often physically combined with S-CSCF type servers so as to constitute so-called “I/S-CSCF” servers—that, at the time of registering a user equipment interrogates a home subscriber server (HSS) in order to be able to select an S-CSCF server that possesses the characteristics that are necessarily required (and also, where appropriate, optionally required) for reaching the level of service to which the user has subscribed. Each HSS server contains a client database and is thus the equivalent in IP networks of the home location register (HLR) servers that are used in networks of the global system for mobile communication (GSM). Each HSS server contains the “profile” of a certain number of user equipments of the network, which profiles comprise their registration states, authentication and location data, and the services to which they have subscribed.
Each user can send a request to subscribe to certain services that are valid for the current connection to an S-CSCF server that has thus been allocated to the user. The general principle is that user equipment can subscribe to a particular technical service by means of an appropriate request (SIP SUBSCRIBE). Thus, when subscribing to the state of a resource, event notifications (SIP NOTIFY) are sent to the user equipment as soon as the state of the resource changes; for example, when the user of a terminal has a voice mailbox on the network, the terminal can subscribe to being notified when a message is left, i.e. it can request to be informed each time a message is recorded in the voice mailbox; likewise, a user equipment can request to be notified about its own registration state, and so on.
Initial subscription requests are sent either automatically immediately after the terminal starts or after an application that is installed on the terminal starts, or else as a result of a user action on the interface of the terminal. For each subscription, the user equipment must begin by sending an initial request, and must then periodically send a request to renew the subscription (the subscription is said to be “refreshed”).
For each subscription (whether an initial subscription or a refreshed subscription), the network informs the user equipment of the refresh period desired by the network operator for that subscription. In document RFC 3265, the maximum refresh period associated with the subscription to a particular technical service, or “event-package”, made available by the network is defined by reference to the document that defines the particular technical service; for example, concerning a subscription to being notified that a message has been left, document RFC 3842 recommends a refresh period lying in the range a few hours to a few days (cf. “event-package message summary”).
It should also be recalled that the DNS system is a service making it possible to find information on the basis of a domain name. DNS servers interact with any “DNS resolver” network entity that has sent a DNS request to make available associations between a domain name and information of a certain type, referred to as “resource records”. In particular, naming authority pointer resource records (NAPTRs), as described in RFC 3403, specify substitution rules to be applied to a character string in order to produce a certain result, such as in particular another domain name or a URI. By means of NAPTR records, the DNS system thus makes it possible to make one character string correspond to another character string by making a domain name search. The term “DNS configuration” is used to designate the data recorded at a given moment in a given DNS server.
In the context of the present invention, the term “DNS information” designates any information of a type that might be recorded in at least one DNS server of an IP network.
In order to be able to set up a call via one or more networks, the network/domain to which the caller belongs, referred to below as the “origin domain”, thus needs to know the identity of the network/domain that makes it possible to reach the called user (referred to below as the “destination domain”). However, the caller often knows only the telephone number of the called user, which telephone number is in the public format in compliance with recommendation E.164 or in a private format. In this respect, it should be recalled that the format for public telephone numbers on the international scale is defined by ITU-T recommendation E.164, where the ITU-T is a part of the International Telecommunication Union (ITU) responsible for devising international standards.
Unfortunately, the telephone number does not make it easy to determine the identity of the destination domain; in other words, there is no automatic association between the E.164 identifier and the URI (or URIs) for entering the destination domain. In this respect, it should be observed that a domain may possess a plurality of entry URIs, which may possibly vary as a function of the identity of the calling domain; for brevity in the present document, the term “URI of the destination domain” is used occasionally to cover the entry URI or the entry URIs of that domain.
In order to solve this problem, the origin domain may for example make use of an enumeration (ENUM) application. The ENUM application uses a database belonging to the network to which the origin domain belongs and containing particular NAPTR records defined in RFC 3761. By making a DNS request using an interrogation key (as described below) representative of a telephone number in the E.164 format, the ENUM application makes it possible to discover the URIs that can be used for reaching a correspondent. These URIs point to resources or services associated with the E.164 number of the correspondent, such as for example an email address, a web page, a directory service, fixed or mobile forwarding numbers, or an alias for voice over IP, for videophone, or for instant messaging.
A certain time to live (TTL) is associated with the DNS information supplied by the DNS server to the DNS resolver so that the DNS resolver does not perform a new DNS interrogation each time a request is sent to a given destination. It is said that the DNS resolver “caches” the information for a certain duration. All information that is cached in this way is referred to in the context of the present invention as a “copy of DNS information”.
The DNS system thus enables requests to be routed very effectively. In particular, if a remote IP address becomes unavailable, it is possible for the DNS resolver to make use of other DNS records relating to resolving a given domain name in order to find another IP address to which to send the request, this other IP address having priority that is lower than the IP address that has become unavailable.
Nevertheless, this DNS translation system suffers from a major problem: it is not possible to request a network entity to update its DNS information. This is very constraining for the operator, since it requires the operator to have short TTLs for records so that the nodes of the network can respond in reasonable time to any change to the topology of the network. Nevertheless, such reduction of the TTL has potentially very great impacts in terms of traffic load, particularly for a DNS server used by subscriber terminals.
It is thus observed that in order to reduce traffic load, certain pieces of equipment in the network such as terminals or residential gateways perform a DNS interrogation only on initialization, and thus retain the information received from the DNS server until the next restart, without taking account of the value of the TTL. For such pieces of equipment, any changes that take place in a DNS record are therefore not taken into account until the next restart.
Likewise, if it is necessary to reorganize the network, the operator is compelled to plan DNS changes far enough in advance to be sure that all of the network nodes will see the TTLs of old DNS information expire. Consequently, in the prior art, it is practically impossible to manage reorganization of a network in order to cope with a temporary overload situation.